Many modern computing environments are connected to a network (e.g., a LAN, a wireless network, a WAN, the Internet, etc.). Merely connecting to a network introduces risk of cyber-centric malicious acts such as virus introduction, data theft, denial of service attacks, etc. Connection to such networks are unavoidable in certain settings. For example, an application or applications that run in middleware settings or in the cloud most likely perform at least some communication over the network. In some cases the aforementioned application or applications listen on specific ports for incoming communications (e.g., from a requestor), and respond accordingly (e.g., return a result). The mere presence of a listening port is a vulnerability since a malicious agent could send a barrage of requests (e.g., denial-of-service or other malicious requests) to the listening port, and the listening application could become overwhelmed by the malicious traffic—thus denying service to legitimate requestors.
In some situations, a component that is connected a network is “hardened” against malicious cyber activity, sometimes through port filtering, and sometimes through additional components (e.g., hardware and/or software) that sanitize or otherwise process traffic before damage can be done or to thwart denial of service. Such “hardening” works well when the hardening techniques are integrated into the listening component. However, in many modern computing settings such as in a virtualized environment, user virtual machines might not have the sophistication and/or resources required to ensure such hardening, yet there needs to be some mechanism in place such that user virtual machines are immune to denial of service attacks, while still being able to perform bi-directional communications with service providers in the virtualization environment. For example, a user virtual machine might want to take advantage of services provided by a hypervisor or by a specially-configured ancillary control process.
Unfortunately, legacy designs introduce the situation that a user virtual machine (e.g., a guest process) use a listening port to communicate with another virtual machine (e.g., an ancillary control process), and to do so, the user virtual machine has only legacy techniques to rely on. In one legacy approach to avoiding having an open listening port in the user virtual machine, the user virtual machine communicates through a hypervisor “back door” programming interface that does not use network I/O. Another legacy technique is to integrate “hardening” into each user virtual machine, however such legacy techniques that integrate “hardening” into each user virtual machine are difficult to deploy and manage, at least in that integrating “hardening” into each user virtual machine is far too resource intensive, and at least in that integrating “hardening” into each user virtual machine creates a management problem in that any change in the code to provide hardening would need to be deployed to each user virtual machine. Also, legacy techniques that rely on a hypervisor “back door” application programming interface (API) is deficient at least in that such an API is not hypervisor agnostic, thus setting up the management scenario where each instance of an ancillary control process would have to be configured to operate with a particular hypervisor. What is needed is a way to deploy hypervisor agnostic channels for secure guest agent communications: (1) while not requiring a listening port to be opened in the user virtual machine, (2) while not requiring that hardening capabilities be built into the user virtual machine, and (3) while remaining hypervisor-independent.
What is needed is a technique or techniques to improve over legacy approaches.